A community of devices is a set of devices that can communicate (permanently of periodically), and that are linked by a trust relation. One can refer to “Secure Long Term Communities in Ad Hoc Networks, N. Prigent, C. Bidan, J. P. Andreaux, O. Heen, October 2003, 1st ACM Workshop on Security of Ad Hoc and Sensor Networks (SASN)” to find explanations on communities of devices.
Communities are generally encountered in the following domains: ad-hoc networks, digital home networks, collection of UPnP™ devices, personal area networks, secured wireless networks (e.g. networks according to the IEEE 802.11 standard with WPA—Wifi Protected Access).
An insertion operation happens when a new device has to be inserted in a community. At the end of the insertion operation, the new device belongs to the community. Existing device insertion methods require at least one user action, to authorize the entry of the new device in the community.
FIG. 1 illustrates a first known method to obtain user authorization before effective device insertion. This method of authorization using a trusted device is described in “Frank Stajano and Ross Anderson, The Resurrecting Duckling: Security Issues for Ad-hoc Wireless Networks (1999)”, available at the following address: http://citeseer.nj.nec.com/stajano99resurrecting.html.
In this method, there are four major steps:
In step 2.1, “Insertion request”, a trusted device 2 of a community 5 named Detector detects an insertion request from a new device 1 named New.
In step 2.2, “User request”, the Detector 2 asks the user 3 for authorization. This step can necessitate user authentication on device 2, using state of the art methods (password, biometry . . . ).
In step 2.3, “User confirm”, the user 3 explicitly authorizes the insertion of the new device 1.
In step 2.4, “Insertion confirm”, the authorization is sent to the new device 1.
These four main steps can be secured using cryptographic material. They can be followed by other optional steps to exchange additional key material or protocol related information.
It should be noted that this method does not allow the user 3 to choose the device used to authorize the insertion: only the Detector device 2, i.e. the first device of the community having detected the new device 1, can be used.
FIG. 2 illustrates a second method of authorization using a predetermined controller (direct method) described for example in standard ANSI/IEEE Std 802.11 [ISO/IEC DIS 8802-11] “Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications, 1999”, available at the following address: “http://standards.ieee.orglgetieee802/downloadl802.11-1999.pdr”.
In this method, there are three major steps:
In step 3.1, “User request”, the user 3 directly requests a device insertion, using a user interface of the predetermined controller 4 of a community 5.
In step 3.2, “User confirm”, the user 3 explicitly authorizes the insertion of the new device 1 in the community 5.
In step 3.3, “Insertion confirm”, the authorization is sent to the new device 1.
These three main steps are generally followed by other steps, among which an action from the user on the new device. This method is used in centralized situations and when there exists pre-shared key to ensure trust between community devices. This is the case for 802.11 networks with WEP (Wired Equivalent Privacy) keys and an access point used as a controller.
It is to be noted that this method does not allow the user 3 to choose the device used to authorize the insertion: only the controller device 4 can be used.
FIG. 3 illustrates a third method of authorization using a predetermined controller (indirect method) described in “Ed Callaway et al: Home networking with IEEE 802.15.4: a developing standard for low rate WPAN, IEEE Com. Mag. August 2002, pp. 70-76”.
In this method, there are six major steps:
In step 4.1, “Insertion request”, a trusted device 2 of a community 5 named Detector detects an insertion request from a new device 1 named New.
In step 4.2, “Forward request”, this request is forwarded to a predetermined controller 4 of the community 5.
In step 4.3, “User request”, the controller 4 warns the user 3 upon receiving a request from the Detector device 2.
In step 4.4, “User confirm”, the user 3 explicitly authorizes the insertion of the new device 1 in the community 5.
In step 4.5, “Forward confirm”, the confirmation is forwarded backward to the Detector device 2 and then, in step 4.6, “Insertion confirm”, the insertion is confirmed to the new device 1.
It is to be noted that steps 4.5 is not mandatory; in a variant, the controller 4 may directly confirm insertion to the new device 1.
These six main steps can be secured by the use of some keys or other cryptographic material. They can be followed by other optional steps to exchange additional key material or protocol related information.
But this method, as the previous ones does not allow the user 3 to choose the device used to authorize the insertion.
In view of the methods described above, we can see that no known prior art method lets the user choose the device that he wants to use for authorizing insertion of a new device. Either the detector device or a predetermined controller device must be used.